This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
Ok I can think of a couple reasons why this might happen so Ill cover all the bases.
1: Make sure you replaced your R&R dB design with the matching 8.5x R&R template. There used to be some processing logic in the template that we removed in 7.0 as part of the redesign. I personally distrust a refresh because the template name changed and find a replace is the only way to go to when you upgrade.
2: Make sure you enable the 4 "system" Agents in the new template (Autoreminder, Update Blockers, Rename Room and Purge) with an ID that is allowed to run Agents on your server. You should also make sure you set the Admin Server of the R&R dB in the ACL dialog. This is the "Home Server" for your R&R entries and MUST be the same for all R&R names in that dB; no ServerA for some entries and ServerB for others!!
3: There were some issues with repeating entries in R6 which could allow new requests to double book with them. We developed a tool you can get from L2 to find and fix the R&R entries (by upgrading them to the R7 repeating format). The tool will also make it nicer for your users in that RnRMgr will be able to purge out long running repeating entries as they age out. The tool is named R6RnRFix in case you talk to L2.
4: For the most part RnRMgr does not really care about direct book vs calendar booked; it simply expects entries to contain a specific set of items. It only cares when it has to Decline a reservation (so it knows to send a Decline or not and if the entry should be kept in the dB or deleted). Since your RnRMgr is not declining this should not be a factor.
5: Check your busytime dB. RnRMgr relies on busytime to be accurate so that it knows if a room is free or not. We have gotten intermittent reports of double bookings which we have backtracked to either multiple busytime entries for a given room OR replication conflicts. If you see > 1 entry for any name then you need to rebuild your busytime. If you are clustered you really MUST follow the Technote on how to do it right or you risk getting bad data sticking around and causing problems for you again in the future when you least want it.
6: Check the $CSTrack items on your 2 test reservations. Is the same server processing both requests or is processing happening on different servers. The former could be happening if you have a problem in busytime (#5 above). The latter could be due to a problem w/your cluster getting 'split' for which you need to get some L2 time to diagnose why.
7: When you do your test, so a tell rnrmgr show Room A/Site 1 console command after your first reservation is booked. Make sure you see the date/time as booked:
RnRMgr: Room A/Site 1 is busy from 8/9/2010 9:00 AM to 8/9/2010 9:30 AM
before you create your 2nd booking. You should see the entry in busytime if you see it has a green checkmark on the entry. Then try to double book it and see if it happens. If you can do this then it may be time to get L2 involved to find out how you managed to bypass the busytime lookup.
Bruce
IBM
Feedback response number BKAN886N3V created by ~Lex Nontookonynivu on 08/09/2010